is this factual? IIRC the query fails during ANALYSIS itself so there's no possibility of a DELETE/UPDATE getting executed if the Trino query shows a failure. @kasiafi can you please double check my understanding?

@hashhar I don't think there's a possibility that an operation (like DELETE or UPDATE) got executed though Trino query failed. I would consider that a serious issue.

All operations that do not return a result set fail during analysis, so they never reach execution.

Please note that the success or failure of a query pass-through depends directly on the presence of a result set, not on the operation type. Theoretically, if some DB returned a result set metadata for a DELETE, we would be happy to execute it. cc @mosabua @Jessie212

Thats exactly the point of the warning ... however ... do we know that the query was actually not run on the underlying system .. @electrum was mentioning that maybe a query like a DELETE query is actually passed through .. and run .. and then just fails on the trino side since no result set is returned.. but the query actually deleted records.

So the aim of this PR is to add a warning of whatever the potential behavior is. Could you test and fully verify this @kasiafi and then we can adjust the wording accordingly.

No, the failure happens during analysis of the query. There's no possibility of running a query if it doesn't return a return set. We check whether result set would be returned BEFORE executing the query.

You can verify this behaviour through the various QueryRunners we have (PostgreSqlQueryRunner/MySqlQueryRunner were the ones I verified).

How is that even possible .. Trino verifies a random pass through query string that is valid for the underlying data source without running the query? Does it pass it through for analysis only or something?

How is that even possible .. Trino verifies a random pass through query string that is valid for the underlying data source without running the query? Does it pass it through for analysis only or something? Or does Trino only validate the larger query .. but not the pass through bit .. and if thats the case .. how does it know if that returns a result set or whatever else.

We should discourage using these table functions for executing queries that might have side-effects in the underlying database. Doing that can be problematic in the face of query or task retries if the operation is not idempotent.

How do we word that so users understand? You are just talking about write access and DDL stuff right? Or any other side effects?

Should we just say that users should use this for just for read-only access?

Do all DBs support this syntax?

Postgres has RETURNING, SQL Server has OUTPUT. I don't know about others.

but yes, this statement won't work as it is for all connectors.

What connectors support what syntax? Can we get a list?

Thats basically the documentation for the underlying database .. its a pass through .. so we cant make a list .. we can only refer to the docs of the data source.

I would remove "may grant access to restricted data". If you mean access which would be restricted if the query was run in Trino, then it is equally true for read and write operations.

Regarding "result in data loss", I would reword it. I a user runs a DELETE query, it is their expectation that data will be deleted. "Data loss" sounds like a bug.